1. Field of the Invention
The present invention generally relates to data processing. More particularly, embodiments are provided for tracking breakpoint hits in a program being debugged.
2. Description of the Related Art
Inherent in any software development technique is the potential for introducing “bugs”. A bug will typically cause unexpected results during the execution of the program. Locating, analyzing, and correcting bugs in a computer program is a process known as “debugging.” Debugging of programs may be done either manually or interactively by a debugging system mediated by a computer system. Manual debugging of a program requires a programmer to manually trace the logic flow of the program and the contents of memory elements, e.g., registers and variables. In the interactive debugging of programs, the program is executed under the control of a monitor program (known as a “debugger”). The debugger may be located on and executed by the same computer system on which the program is executed or may be located on a different system from the one the program is executed on, in the case of a distributed debugger.
Conventional debuggers typically support various operations to assist a computer programmer. Each operation allows the programmer to examine the state of program registers and variables at a given point in the execution of a program. A common operation supported by conventional debuggers is a breakpoint operation. A “breakpoint” is a point in the program where execution of the computer program is stopped so that the state of the program can be examined by a computer programmer. As a result, when a computer program is executed by a debugger, the program executes in a normal fashion until a breakpoint is reached. The debugger then stops execution and displays the results of the computer program to the programmer for analysis.
One problem with conventional debuggers is controlling when breakpoints are hit. In a common debugging scenario, a breakpoint in a program is encountered N number of times before arriving at a particular location (e.g., a location at which a programmer intends to begin serious debugging). Often, the programmer desires to return to this location/state in the program when the program is started with different data. To address this need, many modern debuggers can be instructed to break every N times a particular breakpoint is hit (e.g., every seventh time). However, this requires the programmer to count the number of times the breakpoint was hit during a test run. The programmer may not have been aware ahead of time of the need to count breakpoint hits, or the act of counting breakpoints is simply too cumbersome or error prone to be considered practical by the programmer. As a result, this breakpoint feature is underutilized in most debuggers.
Therefore, a need exists for controlling when breakpoints are hit in a debugging environment.